想要讓 GitHub Copilot 串其他 AI 平台的 model 到 GitHub Copilot 在 Organtization 來使用，行不行？
行，當然行！
看 GitHub 設定 API key 的選項：
基本上主流的幾家 AI 平台都支援了！
GetCreationTimeUtc / GetCreationTime 其實都會有同樣的問題。
更正確地說 .NET 對檔案的 CreationTime 在 Windows 與 Unix-like (macOS、Linux…等，後面都統一稱呼 Linux) 的 OS 上定義不同。
目前手上常用來建置與發佈程式的 CI/CD 服務與架構系統，大略可簡化為 "GitLab 的雲端服務 + 地端主機上所運作的 Docker"。
目前手上常用來建置與發佈程式的 CI/CD 服務與架構系統，大略可簡化為 "GitLab 的雲端服務 + 地端主機上所運作的 Docker"。
在 GitLab.com 申請好的帳號與建立第一個專案的 Repo 之後，就可以進行 Pipeline 的使用。
根據 ChatGPT 對 GitLab 中的 Pipeline 其定義是：
在程式碼變動時，自動執行 CI/CD（Continuous Integration / Continuous Delivery）流程。
技術一點的說：
當程式碼有異動的時候時，GitLab 會依照 .gitlab-ci.yml 的設定，根據 Pipeline 中所設計的 Stages (階段)，如: 建置、測試、部署…等，來自動化的執行一連串 Jobs (工作)。
在使用 GitLab 進行專案管理時，透過範本建立專案可以大幅減少初始化設定的時間。
這篇來介紹一下如何在 GitLab 中使用 .NET 專案範本 (dotnet template) 建立第一個專案，從建立 GitLab Project、套用範本，到完成基本的專案結構與設定。
這樣可以快速建立標準化的 .NET 專案環境，為後續的版本控制與 CI/CD 自動化流程奠定一定程度的基礎。
當前手上處理的系統，整體的程式架構概念可以簡化成：
HW/FW ←→ CLI ←→ GUI
HW/FW 的程式，大多是透由 C/C++ 撰寫，這部分有專業的人員處理開發。
此系統中的 CLI 與 GUI 這兩部分的程式，則是透由 .NET 開發的。也因此隨著 .NET 的跨平台發展，便得以讓這兩部分的程式，皆可以很有序地從 Windows 轉移至 Linux 當中運作。
而在 CLI ←→ GUI 的資訊交換處理，則有大一部份仰賴著使用 .NET 當中的 Named Pipe。
在電腦的 Process 與 Process 之間要相互通訊（IPC, Inter-Process Communication），粗略的來分可以有兩種方式：
以下列出對照：
| Pipe | Socket | |
|---|---|---|
| IPC | ✔ | ✔ |
| 跨電腦 | ✔ (需在 Windows 透過 SMB 服務) | ✔ |
| 效能 | ⭐⭐⭐ | ⭐ |
| 跨網路通訊 | ❌ | ✔ |
| 使用難易 | 易 | 難 |
隨著作業系統的升級或發展過程，在當前安全威脅日益高張的年代，當然作業系統的相關安全性與設計也會隨之強化。
硬體的驅動程式是會跟作業系統 (OS) 直接作動的，所以從安全性的角度來看，隨著時間的推進而造成一些外部裝置的驅動程式過於老舊，沒有跟著新版作業系統的安全性設計而改版，產生與新版作業系統發生不相容問題，也不難理解。
但是就這樣把問題都推給微軟，說通通都是 Windows 11 的錯，這就很難令人理解了🤔
反觀果粉就不會有這種心態…很妙😏
(圖片取自 Gogoro 官網活動)
2026/1/26~2026/2/1 有到 7-ELEVEn 換電站交換電池的 Gogoro 車主，可獲得一點小確幸唷！
透過 .NET API 的 Process 所提供記憶體資訊的屬性運用，可以自我監測 .NET 應用程式佔據記憶體的狀況。
以下列舉三個屬性來介紹：
| 屬性 | 意義 |
| PagedMemorySize64 | 可被分頁到磁碟的記憶體數字 |
| PrivateMemorySize64 | 程式跟系統請求使用的專用記憶體數字（不會跟其他行程共用的部分） |
| WorkingSet64 | 實際駐留在 RAM 的記憶體數字 |
在前篇這樣的兩個應用程式的撰寫在 Windows 上執行時是可以順利完成所需的要求。
但一旦放到 "非 Windows" 上的環境執行時，卻發生了異狀：
應用程式 A 居然找不到應用程式 B 所建立的 Mutex。
發生了執行 30 次(每次等待 1 秒後再找) 後，直接結束應用程式 A 的情況。
難道？？？
名詞定義：
Process - 已被載入到記憶體中執行的 Program 。
應用程式 A 需要等待應用程式 B 完成動作 C 之後，才能繼續執行；換句話說，在 B 執行完 C 之前，應用程式 A 必須被 blocked（阻塞）或 paused（暫停）。
這樣的需求，在現代化的作業系統的設計中，有很多種方式可以完成，例如：signal、pipe、mutex、semaphore…等。
在 iThome 舉辦的 iTHelp 2025 鐵人賽當中發表了 "莫名其妙就跟世界等級的 OpenSource 專案攪和了!?" 系列文。
其中展示了：
三種桌面環境中的 .NET 裝置端應用程式，並使用了 GStreamer 的技術來播放多媒體資訊，而其中 Samples 底下共有兩個專案。
一個是純 Console 的專案；一個是使用 Avalonia 的 UI 專案。
如果在 WSL 中已安裝 Ubuntu - 22.04 的環境，要如何升級到最新 LTS 版本呢？
在 Microsoft Store 的 Ubuntu 的描述當中，看到了這樣的設定：
sudo do-release-upgrade
在 iThome 舉辦的 iTHelp 2025 鐵人賽當中發表了 "莫名其妙就跟世界等級的 OpenSource 專案攪和了!?" 系列文。
其中 "EP 30 - .NET + AvaloniaUI + GStreamer 跨平台" 裡，有展示了透過 WSL 在 Ubuntu 的環境中使用 GStreamerPlayer 的應用程式 (透過 .NET + Avalonia UI + GStreamer 的技術)，來透過 GStreamer 的技術播放影片。
dotnet 在 macOS 安裝後，要能完全移除其實需要一點 CLI 的知識外，也要多研讀一下 Microsoft Learn：
如何移除 .NET 執行階段和 SDK 的介紹。
或是使用 ".NET 解除安裝工具" 來進行。
但如果不介意統一用 brew 來安裝 dotnet 的時候；再加上一點點小技巧，那其實管理、使用與解除安裝時都會相對方便的。
在 iThome 舉辦的 iTHelp 2025 鐵人賽當中發表了 "莫名其妙就跟世界等級的 OpenSource 專案攪和了!?" 系列文。
其中 "EP 30 - .NET + AvaloniaUI + GStreamer 跨平台" 裡，有展示了在 macOS 當中使用 GStreamerPlayer 的應用程式 (透過 .NET + Avalonia UI + GStreamer 的技術)，來透過 GStreamer 的技術播放影片。
如果不是很能接受 Homebrew (或稱 brew) 只能在 "Terminal (終端機)" 當中透過指令操作 (CLI) 的話，可以試試看 WailBrew 這套軟體。
雖然是一套滿近期才推出的軟體，但實際安裝操作後看起來開發作者是還挺用心的。
值得一用~~~
GStreamer 是一個開源、跨平台的多媒體框架，最初由 Erik Walthinsen 於 1999 年開發，目前由 GNOME 社群與多方貢獻者持續維護。它的主要目標是提供一個高度模組化且可擴展的架構，方便開發者在不同平台上處理涵蓋：音訊 (Audio)、影像 (Video)、字幕 (Subtitles) 以及串流傳輸 (Streaming)...等類型的多媒體資料流。
(圖片取自 gstreamer 官網)
在 macOS 上可以透過直接在 GStreamer 官網下載 *.pkg 或是透過 Homebrew 來安裝。